home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000101_news@columbia.edu _Tue Jul 30 13:01:37 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id NAA02876 for <kermit.misc@watsun.cc.columbia.edu>; Tue, 30 Jul 1996 13:01:36 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id NAA27965 for kermit.misc@watsun; Tue, 30 Jul 1996 13:01:34 -0400 (EDT)
  4. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!usenet.eel.ufl.edu!tank.news.pipex.net!pipex!news.be.innet.net!INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!news-res.gsl.net!news.gsl.net!ix.netcom.com!netcomsv!uu3news.netcom.com!lia!glenn
  6. From: glenn@ia-us.com (Glenn Herteg)
  7. Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
  8. Message-ID: <1996Jul30.164039.1803@ia-us.com>
  9. Reply-To: glenn@lia.com (Glenn Herteg)
  10. Organization: IA Corporation, Emeryville, CA
  11. References: <CROTEN.96Jul24005129@crl.crl.com> <4t63nh$imc@samba.rahul.net> <CROTEN.96Jul27005455@crl.crl.com> <CROTEN.96Jul27022451@crl.crl.com> <1996Jul28.193939.943@ia-us.com> <CROTEN.96Jul28153957@crl.crl.com>
  12. Date: Tue, 30 Jul 1996 16:40:39 GMT
  13. Lines: 63
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:5673 comp.dcom.modems:146125
  15.  
  16. >glenn> Normally, I connect to the modem by setting the serial port to 19200 
  17. >glenn> baud. ...        (I've tried a 19200 baud modem, and the poor 
  18. >                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  19. >glenn> 68030-with-two-wait-states in the 3/80 is overloaded at that speed, and 
  20. >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  21. >glenn> must invoke flow control regularly to choke back the transfer rate.)
  22. >
  23. >I wonder if its really your CPU.  You imply you're using a on-motherboard 
  24. >serial port, if I read you correctly .. mind you, I'm no expert on Sun 3/80 
  25. >hardware, so I don't know how many serial ports the motherboard on that 
  26. >beast could support .. just guessing.  
  27.  
  28. The 3/80 has only the on-board serial ports, and no direct way to expand
  29. (unless there's some SCSI or Ethernet box on the market, with a Sun-3
  30. driver, that would support terminal ports).
  31.  
  32. >glenn> I've learned that if
  33. >glenn> the transfer gets into this state but eventually completes, the 
  34. >glenn> *received  file must* be checksummed for integrity outside of 
  35. >glenn> Kermit, because the Block Check 3 on the packet level was 
  36. >glenn> inadequate to ensure a reliable transfer.
  37. >
  38. >I get the same sort of behavior .. with an internal modem, low CPU loading, 
  39. >and rtc/cts flow control.  You earlier mentioned that the misbehavior was, 
  40. >you suspected, at the device-driver level.  Perhaps it is independent of 
  41. >these other issues.  
  42.  
  43. Frank has indicated the likely problem; I'll upgrade my kermit and run
  44. some tests.  I had not done the upgrade before because the version I use
  45. seemed otherwise fine, there was a clear workaround, and I felt I had no
  46. right to expect a protocol to work when I'm telling it to depend on a
  47. transport known to be broken.  Frank seems to feel otherwise, so okay,
  48. I'll take up the challenge.
  49.  
  50. (The other reason I didn't upgrade had to do with the default behavior
  51. on transferring partial files.  It's possible in the 190 version to have
  52. partial files left around, and you get no notice of this.  Oh, yes, I
  53. suppose the fullscreen display would tell me that at the end of the
  54. transfer.  But if I'm using an xterm [for instance; lots of terminals
  55. have this "problem"] then the fullscreen display flips into an alternate
  56. screen, which [kazaam!] disappears once the transfer is done.  There
  57. went my notification of success or failure.  [To fix this, I think a
  58. simple success or failure notification, and the name of any partial file
  59. left hanging around, ought to be repeated on the original screen once
  60. fullscreen mode ends.]  I've modified the terminfo entry for xterm to
  61. form one I call "kterm" without this alternate-screen ability, but I
  62. generally forget to use it.  And I suppose there may be an option to
  63. turn off this partial-file behavior [I don't remember now], but I just
  64. didn't feel a need to play around with it before.)
  65.  
  66. >Oh, yes, before I forget .. I've got rts/cts flow control set up in both 
  67. >C-Kermits, fore-and-aft, in their .kermrc files.
  68.  
  69. Bad news, as Frank has pointed out.  I wouldn't even try the suggested
  70. fix, since (if I recall correctly) nowhere in the manuals is it suggested
  71. that you really have the proper control on both the RTS and CTS lines.
  72. Sun has a patch for the tty driver to supposedly fix all this, but only
  73. for SPARC machines.  Software flow control, bad as it is, is probably
  74. the best solution for you.
  75.  
  76. Glenn Herteg
  77. glenn@ia-us.com
  78.